

----------------------------------------------------------------------------------------------
# Task 분해 (Sequential)
- stage 3
  0. [Python Code]
    - stage 2 쪼개진 결과물 중 일부만 입력으로 사용
      - 입력: `C-###_claim_information.json`
      - [청구권/청구취지/청구원인]만 추출하고 조립
    - 조립 정보는 `C-###_input_legal_facts.json`으로 저장

  1. [Map-Reduce]-[요건사실 쿼리 생성 + DB 검색 + 결과 조립]
  1.1 [쿼리 생성]
    - 개별 청구권에 대한 요건사실 쿼리 생성[Gemini-3.1-Flash-Lite-Preview/reasoning=high/verbosity=low]
      - 입력: `C-###_input_legal_facts.json` + Default_Agent/Keywords_Criteria.txt
    - 생성쿼리는 `C-###_query_legal_facts.json`으로 저장

  1.2 [DB 검색]
    - 생성 쿼리로 Weaviate DB 검색 
      - 입력: `C-###_query_legal_facts.json`
      - 요건사실 중요도 순으로 상위 6개만 추출 = 요건요소 6개
    - 검색결과는 `C-###_legal_elements.json`

----------------------------------------------------------------------------------------------

Stage 3 분해 작업 업데이트

task_0: 청구권별 쿼리 생성용 정보 조합 -- ok
task_1_1: 청구권별 쿼리 생성 -- ok
task_1_2: 청구권별 쿼리 적용 DB 검색 및 결과 도출 -- ok (종선이 결과 보기 -- 아마도 Claude Haiku 4.5 사용?)
<maybe>
task_1_3 [Gemini-3.1-Flash-Lite-Preview/reasoning=medium/verbosity=medium] 
  - task_1_2 결과물로 `C-###_claim_description.json` 항목에 연결하여 요건요소별 요건사실 서술 추출
  - 작업 내용: 추출한 요건사실의 요건요소 항목별로 청구권의 F-###과 연결하여 요건사실 묘사
</maybe>


[수정 작업]
쿼리 DB 적용해서 결과를 가지고 오는 방식을 prompt로 정교하게 제어할 것 --> 간단하게 통제했음 
[쿼리를 DB에 적용해서 가져올 결과물: `metadata`의 level1_1, level1_2 두 개만]으로 결정

----------------------------------------------------------------------------------------------

task_2_0 [Python Code]
[정보조립]
IN: 
  - C-XXX_legal_elements.json
  - C-XXX_query_info_legal_facts.json
[추출항목]
  - C-XXX_query_info_legal_facts.json 원본그대로
  - 아래로 stack
    - legal_elements: 
      - "rank:k"의 level_2 [if level_2 doesn't exist (or null), skip / k=1~4]
        - 최대 4개의 level_2가 존재 가능
        - 만일 `rank:i` & `rank:j` (i≠j)의 `level_2`가 동일하면, i와 j중에서 앞선 값의 `level_2`만 기록

OUT
  - `C-XXX_info_D_R.json`

task_2_1 [LLM 추론: 예상항변 + 재반박 도출]
[Gemini-3.1-Pro-Preview/reasoning=high/verbosity=high]

IN:
  - `C-XXX_info_D_R.json`
OUT:
  - `C-XXX_D_R.json`

프롬프트에 사용할 정보 항목들 

[정보 필드]
- claim_id / 청구권 ID
- claim_title / 청구 개요
- plaintiffs / 원고
- defendants / 피고
- claim_statement / 청구권 내용
- relief_summary / 청구취지
- cause_summary / 청구원인
- legal_elements / 요건사실의 요소 --> 정규화해서 정보 읽기: `가. 피보전채권에 대한 입증책임(증명책임)` --> `피보전채권에 대한 입증책임(증명책임)`로 읽기

[추가 정보필드]
`C-XXX_claim_information.json`에서 
  - source_fact_ids / 법률행위 ID
  - facts 
    - fact_id / 법률행위 ID(F-XXX)
    - source_bo_id / 행위 ID
    - type / 법률행위 구분
    - date / 주요 날짜
    - parties / 당사자
    - object_spec / 행위의 대상
    - action / 당사자의 행위 묘사
    - evidence_refs / 서증 ID
    - legal_calculation_object / 기초적인 계산을 위한 정보 항목


예상 항변과 재반박 전략 수립
-->


# 정보 처리 1(information processing 1)
- claim_id / 청구권 ID
- claim_title / 청구 개요
- plaintiffs / 원고
- defendants / 피고
- claim_statement / 청구권 내용
- relief_summary / 청구취지
- cause_summary / 청구원인
- legal_elements / 요건사실의 요소 --> 정규화해서 정보 읽기: `가. 피보전채권에 대한 입증책임(증명책임)` --> `피보전채권에 대한 입증책임(증명책임)`로 읽기

# 정보 처리 2(information processing 1)
- legal_element 항목들에 대해서 아래 정보들을 연결
  - fact_id의 F-###
  - type
  - parties
  - object_spec
  - F-###의 action
  - evidence_refs의 E-###
  - credibility

# 상대방 예상 항변/부인/절차 후보 선정 방법
- 읽어들인 Data에서 "청구권별 요건요소와 요건사실에서 파생되는 전형적 다툼"만 고려
- 반드시 관련 F-###/E-###를 찾을 수 있는 것만 채택
- 예: 소멸시효(기산점), 변제/상계, 무자력 부인, 피보전채권 부인 등
- 제약조건(must follow): 반드시 가장 유력한 후보 2개 이내로 선택 
 
# 유효 후보 조건(모두 충족):
- 트리거 매칭 legal_element(요건요소) >=1
- 매칭 element의 F-### >=1
- 매칭 element의 E-### >=1

# 점수(결정형):
- `score = 10*매칭 element 수 + 2*credibility가 high/medium인 fact 수 + evidence 수
- 동점이면 후보 `항변 - 부인 - 절차` 순서로 피고의 예상 항변 우선 순위 결정

# `핵심 쟁점`:
- `{대표 element명} 충족과 증거연결(E-###/F-###)의 충분성으로 해당 항변 배척 가능 여부가 쟁점이다.`

# `재반박`:
- `원고는 {대표 요건요소 항목(element_id)} 및 연결 사실·증거를 통해 상대방 주장의 요건사실 부합성을 탄핵할 수 있다.`

# `근거(사실/증거/법리)`:
- `{element_id들}; F:{fact_id들}; E:{evidence_index들}`
- 각 id 목록은 중복 제거 + 오름차순

# `신뢰도`:
- High: `element_id >=2` AND `evidence_index >=2`
- 그 외 유효 후보: Medium

# Markdown Layout (exact)
- `# 항변/재반박 매트릭스`
- 반복: `## 청구 ID - C-### - 항변/재반박 k`
- 표:
  - `| 항목 | 내용/세부 |`
  - `|---|---|`
  - `| 유형 | [`항변/부인/절차` 중 택 1] |`
  - `| 상대방 예상 항변/주장 | ... |`
  - `| 핵심 쟁점 | ... |`
  - `| 재반박 | ... |`
  - `| 근거(사실/증거/법리) | ... |`
  - `| 신뢰도 | High 또는 Medium |`"


------------------------------------------------------------------------------------------

리서치 프롬프트 

나는 현재 법률 분야에서 완전하 vertical AI agent를 개발 중이다. 이 에이전트는 원고를 대리하는 변호사가 사용자가 되는 에이전트이다. 사용자가 고객상담문서(client_meeting.md)와 모든 증거문서들의 정보를 망라한 evidence_all.json을 입력하면 그로부터 에이전트가 여러 단계에 걸쳐 작업을 진행하여 최종적으로 "소장(complaint)" 문서를 생성하는 것이 에이전트의 주된 작업 workflow이다. 

`Legal_Agent_V4_v5_copy.yaml`에서 `stage1_사건개요파악` 작업을 실행하여 얻은 결과물들은 `Stage_1_Results`에 저장되어 있다. Stage 2 작업은 `stage_1_task_A_B_C.yml`을 우선 실행하고 (결과물은 `Stage_2_Results/Task_A_B_C` 폴더에 있음), 다음으로 `stage_2_claim_description_mapreduce.yml`을 실행하여 `C-###_claim_information.json`을 얻고 (`Stage_2_Results/Task_D_pre` 폴더에 저장되어 있음), 이후 `C-###_claim_description.json`을 얻는다(결과물은 `Stage_2_Results/Task_D` 폴더에 저장되어 있음). 

이제 Stage 3에서는
1. Stage 2에서 얻은 청구권들에 대한 요건사실을 외부 DB에서 검색하기 위해 우선 청구권별 정보를 조립하고
  - `C-###_query_info_legal_facts.json`을 얻음(`Stage_3_Results/쿼리용정보` 폴더에 존재)
2. 조립한 청구권별 정보를 바탕으로 외부 DB 검색을 위한 쿼리를 생성하고,
  - `C-###_query_for_legal_facts.json`을 얻음(`Stage_3_Results/쿼리` 폴더에 존재)
2. 쿼리를 외부 Weaviate DB에 적용하여 결과를 받아오고, 
  - `C-###_legal_elements.json`을 얻음(`Stage_3_Results/쿼리검색결과_v3` 폴더에 존재)
3. 그것들을 결합하여 청구권/청구취지/청구원인에 대한 피고의 예상 항변과 재반박을 추출하기 위한 정보를 조립하며,
  - `C-###_info_D_R.json`을 얻음(`Stage_3_Results/DR_Info` 폴더에 존재)
4. `C-###_info_D_R.json`을 바탕으로 LLM을 통해 피고의 예상 항변과 그에 대한 재반박을 도출한다. 

4번 작업을 위한 프롬프트를 작성하기 위해서 아래 요구사항(<요구사항>)을 제시한다. 

<요구사항>

</요구사항>

<요구사항>을 반영하여 각 청구권별로 최대 2개 이내로 가장 가능성이 높은 피고의 예상 항변과 그에 대한 재반박 전략을 도출하는 매우 정교한 프롬프트를 작성하라. 작성한 프롬프트는 `stage_3_task_2_v0.txt`로 생성하라. 


-------------------------------------------------------------------------------------------

task_2_0: 예상항변/재반박 추출용 정보 조립 [Python Code]
  - 청구권별: task_0 파일 + task_1_2 (or task_1_3)
  - 조합정보: [청구권/청구취지/청구원인/요건요소/요건사실/F-###(fact_id)/F-###별 핵심 정보]

task_2_1: 청구권별 예상항변/재반박 추출 [Gemini-3.1-Pro-Preview/reasoning=high/verbosity=high]

task_2_2: 청구항변재반박전략서.md 조립 [Python Code]
IN:
  - client_goal.json
  - C-###_info_D_R.json
  - C-###_defense_rebuttal.md

* client_goal.json:
  - primary_goal
  - summary_key_incidents
  - key_facts
* C-###_info_D_R.json
  - claim_id
  - case_kind
  - claim_title
  - plaintiffs
  - defendants
  - claim_statement
  - relief_summary
  - cause_summary
  - facts
    - fact_id / F-###
    - type
    - parties
    - object_spec
    - action
  - evidence_refs / E-###    ==> F-### + E-### 조합으로 묶기
  - legal_elements / 정규화하여 사용(예: `다. 보증채무이행청구` -> `보증채무이행청구`)
* C-###_defense_rebuttal.md
  - C-###별 2개의 표들을 C-### 정보에 포함






- 기계적으로 markdown 문서를 조립
  - 청구권 마스터 표
    - claim_id
    - claim_title
    - case_kind
    - claim_statement
    - relief_summary
    - cause_summary
    - legal_elements
    - evidence_refs
    - fact_id
    - claim_id별 항변/재반박 2개 표를 stack

  - 서증/법률행위 연결 표 (python code로 해결할 것)




----------------------------------------------------------------------------------------------
[이전 계획]
  
  1.3 [검색결과 문서화]
    - 추출한 요건요소에 대한 요건사실 서술 [Gemini-3.1-Flash-Lite-Preview/reasoning=medium/verbosity=high]
        - 입력: `C-###_legal_elements.json` + `C-###_input_legal_fact.json`
    - 개별청구권별 요건사실 문서(JSON)생성: `C-###_legal_facts.json`

  2. [Python Code]-[종합입력정보 생성]
    - 입력: `C-###_legal_facts.json`(개별청구권별 요건사실 정보) + 기존 `C-###_claim_information.json`
    - 정보 조립 및 문서 생성 
      - 조합정보: [청구권/청구취지/청구원인/요건요소/요건사실/F-###(fact_id)/F-###별 핵심 정보]
      - 문서: `C-###_key_info.json`
        - 문서 JSON Schema 미리 지정

  3. [Map-Reduce]-[예상항변-재반박 도출]
    - 개별 청구권별 작업[Gemini-3.1-Pro-Preview/reasoning=high/verbosity=high]
      - 입력: `C-###_key_info.json`(개별 청구권 조합 문서)
      - 청구취지에 대한 가장 가능성 높은 예상항변(요건요소별) 2개 및 그에 대한 재반박 논리 2개 생성
      - 개별 청구권 조합 문서 재조립: 청구권/청구취지/청구원인/요건요소/요건사실/예상항변/재반박
      - 재조립한 문서는 `C-###_essential_info.json`로 생성

  4. [Python Code]-[기계적으로 청구항변재반박전략서.md 생성]
    - 입력: `C-###_essential_info.json` + `client_goal.json`
    - 청구항변재반박전략서.md 조립
      - 1. 사건개요: client_goal.json 사용
      - 2. 당사자 구조
      - 3. 청구 마스터 표
        - 3.1 청구권 구조도: [청구ID/청구권/사건종류/원고/피고]
        - 3.2 청구권 상세 정보 표(청구권 갯수만큼 stack)
            - 제목: C-###: [string]
            - 항목(1열): 청구취지, 청구원인, 요건요소, 요건사실, 서증목록, 예상항변, 예상항변 요건요소, 재반박, 재반박 요건요소
            - 내용(2열): 항목별 내용 기입

---
  5. 청구 및 서증 리스크(Optional) 
    - 추후 feedback / 자체 연구 진행
    - 이 과정이 background에서 독립적(standalone)으로 자동 진행되어 최종적으로 검토문서에 반영하는 방법을 생각 중

---





-------------------------------------------
CODEX 사용 (서브에이전트)

Spawn a subagent to explore this repo.
-------------------------------------------

Stage 3 프롬프트 최적화 리서치용 (Gemini-3.1-Pro-Preview/reasoning=high/verbosity=medium)

Stage 3의 Task 1은 이제 좀 더 업데이트되어, 첨부한 `stage_3_task_1_v3.yml`로 확정되었다. Stage 3의 Task 1 작업에서는 
1. Stage 2에서 얻은 청구권들에 대한 요건사실을 외부 DB에서 검색하기 위해 우선 청구권별 정보를 조립하고
  - `C-###_query_info_legal_facts.json`을 얻음
2. 조립한 청구권별 정보를 바탕으로 외부 DB 검색을 위한 쿼리를 생성하고,
  - `C-###_query_for_legal_facts.json`을 얻음
3. 쿼리를 외부 Weaviate DB에 적용하여 결과를 받아오고, 
  - `C-###_legal_elements.json`을 얻음
4. 그것들을 결합하여 청구권/청구취지/청구원인에 대한 피고의 예상 항변과 재반박을 추출하기 위한 정보를 조립한다.
  - `C-###_info_D_R.json`을 얻음(`Stage_3_Results/DR_Info` 폴더에 존재)

예시를 위해 `C-002_info_D_R.json`, `C-005_info_D_R.json`, `C-006_info_D_R.json`, `C-008_info_D_R.json`, `C-010_info_D_R.json`을 첨부하였다. 

이제 Stage 3의 Task 2에서는 `C-###_info_D_R.json`을 바탕으로 LLM을 통해 피고의 예상 항변과 그에 대한 재반박을 도출한다. Task 2에서 LLM을 통해 실행할 작업 명세를 상세하게 기록한 프롬프트가 `stage_3_task_2_v0.txt`에 제시되어 있다. 이 프롬프트를 Gemini-3.1-Pro-Preview (reasoning=high, verbosity=medium)를 통해서 실행했을 때 `1. 목적달성 정도, 2. 토큰 경제성, 3. LLM 추론 속도`의 3가지 기준을 10점 만점에 9.8점 이상 획득할 수 있도록 최적화하여 재작성하라. 

프롬프트 재작성 시, 기존 프롬프트의 작업 과정을 동일하게 실행할 수 있도록 하라. 


